Mobile IPv6 (MIPv6) is a protocol developed to enable IP mobility in IPv6 networks for IPv6 hosts. Such a protocol allows a Mobile Node (MN) to maintain active TCP (Transmission Control Protocol) connections and UDP (User Datagram Protocol) port bindings while moving from one subnet to another. The current Mobile IPv6 model is based on the MN being assigned a static IP address as its HoA, e.g. at subscription time. When connected through a foreign network, the MN sends Binding Updates (BUs) to its Home Agent (HA) to indicate its current location information, or the Care-of-Address (CoA) that has been assigned to the MN at its current point of attachment. This information allows the HA to forward packets intended for the MN to the current location. BUs are secured by an IPsec security association (SA) that exists between the MN and the HA (e.g. set-up at subscription time). This IPsec SA is normally associated with the static HoA of the MN (source address), the Home Agent address, a Security Parameter Index (SPI) value and the value of the Next Header. The HA uses these parameters for each incoming packet to identify the correct SA to utilize. The IPsec engine in the MN and HA makes use of this SA in securing the BU and Binding Acknowledgment (i.e., in authenticating the MN sending the message and verifying the integrity of the message).
Currently, an MN provides the HA its Home IP Address to identify itself. In particular, this means that the HA processes the BU after the IPsec engine has validated the authenticity of the BU. Since the BU sent to the HA from an MN is secured by IPsec, the Mobile IP processing of the BU message in the HA is carried out only after the BU has been processed by the IPsec engine. The Mobile IP module only processes authenticated BUs because the responsibility of ensuring the authenticity is passed on to IPsec.
However, real deployment models and privacy issues may cause the MN to use techniques, such as those proposed in RFC3041, to generate a dynamic HoA instead of being assigned a static one. In such cases, since the MN is using a dynamic HoA, the MN needs first to register the dynamic HoA with its HA before the HA can start defending the HoA and forward incoming packets to the MN, and then send a BU message to the HA to create a binding cache for the CoA. In order to secure these messages (to avoid flooding of the HA), the MN has to prove its identity to the HA via an identifier that is not its IP address in order for the HA to accept the HoA being proposed by the MN (i.e., for the messages to successfully pass the processing of the IPsec engine). Only after the HA has accepted the HoA will a BU sent by the MN be processed by the MN.
Currently, in Mobile IP, there is no way for an MN to register a Home Address (HoA) dynamically created by the MN with an HA in a secure way. However, this missing procedure will soon be required to allow the deployment of CGA (Cryptographically Generated Address) solutions, or dynamic home address assignment procedures required in RFC 2977.
CGA and other proposed solutions define schemes to allow the MN to prove that it owns the claimed IP addresses (Home Address and Care-of Address). These solutions require that in some situations (e.g., for solutions that rely on public keys when the private key is corrupted), the MN computes a new Home Address and registers it with its home network; but as indicated above, such a procedure does not exist, yet. Alternatively, the presence of some infrastructure (such as AAA servers) can be relied upon. Also the current Mobile IPv6 model relies on the MN being assigned a static HoA, and this may not be the most efficient model for real large scale deployment, besides not allowing for dynamic HoA assignment as required in RFC 3041 or CGA.